Plasma Cash における challenge

---.icon

challenge パターン

---.icon

challenge に必要なトランザクション履歴

Challenge of type (iii) is unclear. From my understanding, an invalid output A can be created and spent into B and then into C (all owned by same user colluding with operator) i.e A->B->C. C is withdrawn providing B and C. A may be withheld (not published). How would challenge (iiii) be made? Even if A were published, can the challenge be blocked by providing B?

bharathrao：(iii) のタイプの challenge がよくわからない。自分の理解では、不正なコイン A が生成され、A が使用されて B、B が使用されて C となる（全てのコインはオペレータと共謀する同じユーザーに保有されている）。C は、B と C を提出することで引き出される。A は withhold される（公開されない）かもしれない。このとき、challenge (iii) はどのようにしてつくられる？A が公開されていたら、B を提出することで challenge をブロックできるのでは？

As I am understanding, the idea is that the chain creates an invalid output A, then a child of A, B, then a child of B, C, and then tries to exit C.

vbuterin：その通りで、不正なコイン A が生成され、B は A の子、C は B の子。で、C を exit しようとしている。

I would challenge by providing the parent of A.

vbuterin：A の親を提出することで challenge できる。

What if A is deposit on root chain that is supposed to create a new coin? Do deposits on root-chain have parents?

bharathrao：A が親チェーンでのデポジットによって生まれたコインだとしたら？親は存在しないのでは？

If A is a deposit on the root chain, then A can’t be invalid.

vbuterin：A が親チェーンでのデポジットに対応しているなら、A が不正であることはない。

Im just claiming A exists. Lets say there are 20 different coins from real deposits on root chain. Im claiming A is the 21st coin (doesn’t really exist on root and not published). How can challenge (iii) be submitted?

bharathrao：自分は A の存在を仮定したいだけ。例えば、親チェーンでのデポジットに対応した 20 の異なるコインがあり、A は 21 番目のコインだとする（親チェーンに存在せず、公開されてもいない）。このとき、どうやったら challenge (iii) を行える？

I’m guessing that naive way out of this is to require the root chain entry and entire coin history MUST be provided for every withdrawal.

bharathrao：これを解決する素朴な方法は、全ての引き出しについて、親チェーンでのエントリから始まるコインの全履歴の提出を義務づけることだと思う。

Of course A,B,C is the shortest chain but nothing prevents the operator from creating 10K transfers before attempting a withdrawal. This would create a very large withdrawal tx.

bharathrao：もちろん、A・B・C は最短なチェーンのパターンだが、オペレータは 10,000 回の取引を行ってから引き出すこともできる。（上記の義務づけを前提とした場合）これでは引き出しトランザクションが非常に大きくなってしまう。

The point is that the first invalid or unavailable transfer in the chain is not a deposit, and so it has a parent (which is valid and available), and so a challenge can be done based on that.

vbuterin：ポイントは、チェーン内の最初の不正かつ unavailable な取引がデポジットと対応していないかどうか。対応していなければ（正当かつ available な）親がいるので、それに基づいて challenge は成立する。

---.icon

double spend な exit

https://gyazo.com/57cc1e2f621069263a4b39302bedbefa

I’m not sure I see the possibility of the “Exit Double Spend” happening.

gakonst：double spend な exit がなぜ起こりうるのか分からない。

It is my understanding that for someone to spend a transaction, it must be signed over to them by its previous owner. As a result, if Charlie (Block 4) has a transaction signed to him from Bob (Block 3), who has a transaction signed over to him from Alice (Block 2), Charlie is only able to exit Bob’s transaction, since that was the one which was signed to him. If he tries to use Alice’s transaction as the previous one, the signature check should fail, as Alice explicitly signed her transaction over to Bob.

gakonst：自分の理解では、コインを使用するためには以前の保有者の署名が必要。

ブロック 4：Charlie が Bob によって署名されたコインを保有

ブロック 3：Bob が Alice によって署名されたコインを保有

ブロック 2：Alice がコインを保有

とすると、Charlie はブロック 4 のコインのみを exit できる。なぜなら、その署名は Charlie に向けられたものだから。Charlie が Alice のコインを使おうとした場合、署名の検証は失敗する。なぜなら、Alice の署名は Bob に向けられたものだから。

You can imagine that Charlie is another name for Alice, who is also related to the operator. After sending the token to Bob, Alice signed another transaction for Charlie and although it’s invalid, the operator let it through the check.

The signature check will passed, because it’s valid signature.

peara：Charlie が Alice であり、さらに Alice がオペレータである場合を想像してみるとよい。Bob にトークンを送った後、Alice は別のトランザクションに署名して Charlie に送る。これは不正ではあるが、Alice はオペレータなので検証をスルーできる。

peara：署名自体は正当なので、署名の検証はパスできる。

---.icon

同じユーザーが自身に送信を繰り返した UTXO の exit

It looks to me that Plasma Cash (similar to MVP) is vulnerable to a self-transfer-then-exit vulnerability.

kladkogex：Plasma Cash は（Plasma MVP と同様に）同じユーザーが自身に送信を繰り返した UTXO の exit について脆弱性があるように見える。

If Alice has a coin and she transfers it to herself 1000 times, and then she cooperates with the Plasma operator, she seems to be able to exit intermediate UTXOs without a challenge, since only she will be possessing the fraud proofs.

kladkogex：Alice がコインを保有しており、それを 1,000 回自身に繰り返し送信し、オペレータと共謀したとする。このとき、Alice は中間の UTXO を challenge なしで exit できるように思える。なぜなら、fraud proof を保有するのは Alice だけだろうから。

I wonder if it has been addressed anywhere ? In my understanding users are not supposed to store unrelated transactions, so it seems that if Alice sends money to herself, then no one will have proofs because no one will care to save the proofs for these transactions.

kladkogex：この問題に対して何らかの対策はされている？自分の理解だと、ユーザーは自身と関係のないトランザクションを保持する想定ではないため、Alice が自身に送金した場合、誰も proof を保有してはいない。なぜなら、誰もこれらのトランザクションに関する proof を保有したくはないから。

In plasma cash the coin id does not change between transactions, and the plasma contract enforces that every coin can only be withdrawn once

ldct：Plasma Cash では、トランザクションによってコイン ID が変化しない。また、Plasma コントラクトは全てのコインを 1 度だけしか引き出せないように強制する。

What does prevent Alice to exit one of intermediate self-payment transactions (lets supposed the coin is now owned by Bob.

kladkogex：Alice が自身に送信を繰り返す中で生まれた中間トランザクション（現在は Bob がそのコインを保有しているとする）を exit するのを妨げるものはある？

May be one needs to amended exit procedure so that it accepts as a fraud proof any future transaction involving the coinid? (not just the subsequent one?)

kladkogex：あるコイン ID に関する（後続の 1 つだけでなく）未来のトランザクションも fraud proof として認められるように exit の手続きを修正する必要があるのでは？

The exit game as written here only lets you cancel an exit by showing a “direct” spend of the exiting coin; if you modify the game to allow cancelling an exit by showing any future spend of that coin (and don’t change anything else), the construction becomes broken

ldct：ここに記載されている exit ゲームは、exit 中のコインの「直接」使用を示すことによってのみ exit をキャンセルできるようになっている。そのコインの未来の使用を示すことによって exit をキャンセルできるようにゲームを変更する（かつ他には何も変更しない）のであれば、前提が崩壊する。

The exit game here is secure because there is a client rule that a coin owner should be aware of (have inclusion proofs of) all transactions involving the coin, so that whatever intermediate payment Alice tries to exit, Bob knows how to cancel it

ldct：コインの保有者はそのコインに関する全てのトランザクション（の inclusion proof）を知っているというクライアント側のルールが存在するため、ここでの exit ゲームは安全である。よって、Alice がどの中間のトランザクションを exit しようが、Bob はそれをキャンセルできる。

I think this system needs to be modified so that the user explicitly burns the coin before exiting it and provides proof of burn

kladkogex：ユーザーがコインを exit する前にそれを明示的に焼却して Proof of Burn を提出するようにシステムを変更する必要があると思う。

The current mechanism seems to be incredibly computationally consuming. How can I use a system where for each 1c coin I got, I need to check a linearly increasing set of Merkle proofs. If I am paid a $0.01 coin and then I have to first to dowload megabytes of Merkle proofs and then keep on monitoring it forever, how viable is this solution?

kladkogex：現在の仕組みは計算資源を非常に浪費してしまうように思える。1 セント分のコインを入手した場合、どうすればよい？Merkle proof の量は線形に増加し、それをチェックする必要がある。0.01 ドル分のコインを支払われた場合、メガバイトサイズの Merkle proof をダウンロードし、それらを永遠に監視し続ける必要がある。このソリューションにどれだけ実行可能性があるだろう？

If I have $10 as 1000 coins 1c each, the amount of dowload, storage, verification and monitoring I need to do seems overwhelmingly huge and growing linearly with time.

kladkogex：10 ドルを 1,000 個のコインとして保有していた場合、要求されるダウンロード量・ストレージ量・検証量・監視量は圧倒的に大きく、時間とともに線形に増大する。

Explicit burn proof solves all these issues, you simply do not need to store anything

kladkogex：明示的な Proof of Burn はこれら全ての問題を解決し、単純に何も保有する必要がなくなる。

If you have a design that modifies plasma cash with “proof of burn” that solves this problem, feel free to create a separate post (I feel like this one is getting long) and I can look at it

ldct：この問題を解決するために Plasma Cash に Proof of Burn を導入した設計があるのであれば、（それは長文になると思うので）別のスレを立ててほしい。それを見に行きます。